In recent years, enterprises and developers have sought an easy and affordable way to use cloud computing as a way to load and performance test their websites and web-based applications. Cloud computing gets its name from the fact that the machine, storage, and application resources exist on a “cloud” of servers. In cloud computing shared resources, software and information are provided on-demand, like a public utility, via the Internet. Cloud computing is closely related to grid computing, which refers to the concept of interconnecting networked computers such that processing power, memory and data storage are all community resources that authorized users can utilize for specific tasks.
A web site is simply collection of files on a remote server. When a user accesses a website via a browser, Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTPS) message intercommunications take place with the target website. In very simple terms, when a user wishes to view a webpage HTTP requests each of the various files or objects that make up the webpage. These objects may include text, images, JavaScript files, etc. Each of these objects is typically delivered from the host server to the user's browser in a serial manner. That is, a series of communicative actions needs to occur between the browser and server in order for the user to view a specific page of a website. Essentially, the files and objects which comprise the webpage are loaded one-by-one. Due to the request-and-response nature of HTTP, there is a latency associated with each file that is loaded.
Load testing a web-based application or website can involve simulating a very large number (e.g., up to or beyond 1,000,000) of virtual website users via HTTP or HTTP Secure (HTTPS) message intercommunications with a target website. For very large tests, sending and aggregating the test results data generated from all of the load servers to a database available to a dashboard in reel time has been problematic. The huge overhead of receiving, and processing a very large number of HTTP messages containing all of the requests and responses sent from each of the many load servers to the analytic servers responsible for analyzing the test results data can easily overwhelm the resources of the server. In addition, communications bottlenecks can occur wherein messages get queued up in long stacks or lines such that the test results are no longer sent to the database in real-time, and therefore are not available in the dashboards in real-time. In extreme cases, the load test servers can also back up, causing them to not generate the appropriate load on the customers' websites or web applications.
A waterfall chart is another visual tool that developers and businesses use to analyze webpage performance. Waterfall charts are diagrams that allow a user to visualize data that is generated cumulatively and sequentially across the process of loading a webpage. A waterfall chart for a website provides the user with a visual representation of all of the series of actions that occur between a user's browser and the website server when that user wishes to view a specific page of the website. A typical waterfall chart consists of a series of colored bars that extend horizontally across a timeline. Each of the colored bars represents a different activity that happens as the associated object is delivered to the user's browser. For example, a dark green bar may represent a Domain Name System (DNS) lookup wherein the browser looks up the domain of the object being requested. An orange bar may represent a Transmission Control Protocol (TCP) connection process by which the browser and server send and receive acknowledgement that a connection has been made. A bright green bar may represent the so-called “time to first byte”; the window of time between when the browser asks the server for content until the first byte of content is received back. A blue bar may be used in a waterfall chart to indicate the time it takes for the entire content to be sent from the server to the browser.
One problem with existing waterfall charts is that they are entirely static, meaning that once the webpage is fully loaded the timeline information shown by the various colored bars is static on a per user basis, i.e., it does not change. A more useful metric to a developer or website owner would be an active waterfall chart that aggregates and updates website webpage performance on a continuous, real-time basis across a changing number of virtual users and/or multiple webpages associated with a target website.